Since inception, telephones have been equipped with a bell or other audible device, e.g., a “ringer” to alert their users of an incoming call. Today, telephones are equipped with audible devices that play ringtones to alert their users of an incoming call and/or message. These audible devices, which are especially predominant among mobile (e.g., cellular) telephone technologies, commonly support a variety of resident, preprogrammed ringtones that a user of a receiving telephone can select, amend, and/or alter. Modern telecommunication and/or computer networks allow users to download an ever-increasing library of ringtones, thereby providing a wide degree of flexibility, control and personalization, thus changing an otherwise neutral device into something personal, and, in many cases, endearing.
More recently, and again, more predominantly in mobile telephone technologies, a user of a receiving telephone is now able to manually associate the resident, programmed ringtones to a particular calling party's phone number. This way, when a call that has an associated ringtone is terminated to the receiving telephone, the receiving telephone may play the associated ringtone.
To facilitate this in traditional phone systems, the receiving telephone receives information, such as the calling-party's phone number and name, from a telecommunications network that is relaying the call. This information may be relayed to the receiving telephone using, for example, the well-known caller-line identification (“Caller ID”) service, which allows the information to be displayed as textual information (i.e., Caller ID text) to the user of the receiving telephone. In addition to displaying the information, the receiving telephone may match the Caller-ID information to an associated ringtone, and then play the associated ringtone to allow the user of the receiving telephone to identify (and/or determine whether to answer the call from) the calling party without needing to look at the Caller ID text.
This arrangement has several shortcomings. First, the calling party cannot influence the ringtone. That is, the ringtone is determined by the receiving party. This happens because the receiving party (i) chooses a telephone model from a wide variety of telephone models, which generally limits the available ringtones (preprogrammed or otherwise); (ii) selects a ringtone from the available ringtones based on, for the most part, personal choices, and then (iii) associates the selected ringtone to a given calling party phone number.
Second, the receiving party must manually associate a ringtone for each potential calling party to identify each calling party. Thus, the receiving telephone will use a default or generic ringtone for calling party numbers that do not have an associated ringtone. Third, if the user wishes to uniquely identify each calling party, then the user has to associate a different ringtone to each calling party number. Fourth, although a wide variety of ringtones exist, each telephone model generally limits the available ringtones (preprogrammed or otherwise).
Still more recent advances have now made it possible for telephone devices to operate as nodes on a packet-switched network (such as the Internet) and to engage in voice-over-IP (VoIP) or other packet-based communication. With such an arrangement, the calling and called devices may engage in packet-based call setup signaling in order to set up a packet-based call session, and the devices may then exchange real-time packet-based media streams (e.g., voice and/or video) with each other.
For instance, the devices may engage in call setup signaling according to the well known Session Initiation Protocol (SIP) in order to set up a packet-based real-time media session according to the well known Real-time Transport Protocol (RTP), and the devices may then exchange voice or other media with each other as a stream of RTP packets.
In particular, when a user of the calling device requests placement of a call to the called user, the calling device may transmit to a “SIP address” of the called user a SIP “INVITE” message requesting establishment of a packet-based real-time media session (e.g., RTP session) for the call. The SIP INVITE may also specify proposed session parameters such as a media coding scheme, and may identify the actual network address (e.g., IP address) and RTP port at the calling device. A SIP proxy server in the network may then consult SIP registration data to determine the network address where the called SIP address is currently registered, and the SIP INVITE may be routed to that network address.
Upon receipt of the SIP INVITE, the called device may play a ringtone (e.g., default or pre-associated with the calling user) to alert the called user. Once the called user answers the call (e.g., takes the called device off hook), the called device may then transmit to the calling device a SIP “200 OK” message expressing agreement to participate in the session, and typically designating an actual network address and RTP port at the called device. The calling device may then transmit a SIP “ACK” to the called device to confirm that the RTP session is established and ready to begin. The calling device may then begin to transmit to the actual network address/port of the called device an RTP packet stream representing real-time media such as voice or video from the calling user, and the called device may likewise transmit to the actual network address/port of the calling device an RTP packet stream representing real-time media from the called user.